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(54) Anonymous and secure electronic commerce 

(57) Anonymous delivery and payment techniques 
for use in conjunction with electronic commerce are dis- 
closed. A user, upon entering into an electronic trans- 
action with a merchant, provides the merchant with a 
unique identifier. For each transaction entered into by 
this user, the unique identifier provided to various mer- 
chants changes. Upon receipt of the identifier, the mer- 
chant places the identifier on a label on a package con- 
taining the goods to be delivered to the user and pro- 
vides the package to a trusted third party shipper. The 
shipper accesses a database to associate the identifier 
with a particular user's address. The shipper thereafter 
replaces the label with a label containing the user name 
and address and delivers the package to the user. Var- 
ious techniques are disclosed for the generation, stor- 
age, and use of the unique identifiers by the user and 
shipper. Further, an anonymous payment technique 
may be coupled with the anonymous delivery technique 
which allow the shipper to authenticate the payment 
amount agreed to by the user so that the shipper can 
pay the merchant for the goods and recover the amount 
paid from the user. 
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Description 

Field of the Invention 

[0001] The present invention relates generally to elec- 
tronic commerce. More particularly, the present inven- 
tion relates to anonymous and secure delivery of, and 
payment for, goods ordered via a data network. 

Background of the Invention 

[0002] As the number of electronic commerce trans- 
actions increases, privacy becomes more of a concern. 
Some purchasers are reluctant to engage in electronic 
commerce because of the possibility of tracking and pro- 
filing online purchases. As such, these purchasers pre- 
fer conventional "brick and mortar" businesses because 
of the anonymity provided by traditional, especially 
cash, transactions. 

[0003] The major obstacle to providing anonymity in 
online transactions arises from the very nature of elec- 
tronic transactions in that, a product, which is purchased 
online, must be physically delivered to the purchaser. . 
This, of course, requires that the purchaser provide his/ 
her name and address to the merchant so that the prod- 
uct may be shipped. Merchants collect purchase infor- 
mation and use it for marketing purposes, such as mass 
mailings. This anonymity problem is a major obstacle to 
the electronic commerce industry. 
[0004] One solution is described in U.S. Patent No. 
6,006,200 ("Boies et al.") ( in which customer name and 
address information is entrusted to a database of a trust- 
ed third party, such as a shipping company. Each cus- 
tomer receives a unique identifier which is stored in the 
database associated with the customer's name and ad- 
dress. After the database entry is set up, a customer 
may make an online purchase and provide the merchant 
with only the unique identifier. The merchant places the 
unique identifier on the physical package containing the 
purchased item and provides the package to the trusted 
third party shipping company. The shipping company 
then determines the customer name and address based 
on the unique identifier and delivers the package to the 
customer. 

[0005] While the technique described in the Boies et 
al. patent provides some level of anonymity, there are 
several problems with the proposed solution. First, 
transactions in a system which utilizes that scheme are 
so-called linkable, in that one or more merchants may 
collect purchase information over a period of time, and 
the collected purchase information may be correlated 
such that certain information about purchasers associ- 
ated with particular identifiers may be discoverable. Giv- 
en a large time period and a large number of transac- 
tions, even the name and address of the purchasers as- 
sociated with particular unique identifiers may be deter- 
minable with some degree of accuracy. Another problem 
with the Boies et al. technique is that it does not take 



into account payment for the purchased item. Even 
though the delivery mechanism is anonymous to some 
degree, the payment for the purchase provides another 
problem and another lack of anonymity. Since most on- 

5 line purchases are made using a credit card, the mer- 
chant must know the purchaser's name and address in 
order to process the order. Of course, although not ad- 
dressed in Boies et al., anonymous payment may be ar- 
ranged though another trusted third party. However, it 

10 would be logistically difficult to coordinate such a com- 
bination of trusted third parties, purchaser, and mer- 
chant. 

[0006] What is needed in order to stimulate the elec- 
tronic commerce industry is a non-linkable anonymous 
15 delivery technique. Further benefits could be obtained 
if such a delivery technique could be coupled with an 
improved payment scheme which would allow the pur- 
chaser to remain anonymous. 

Summary of the Invention 

[0007] When a user purchases goods to be shipped 
from a merchant, the user provides the merchant with a 
unique identifier. Thereafter, the merchant provides a 
package containing the goods to a trusted third party 
shipper who is capable of associating the unique iden- 
tifier with the user. In accordance with the present in- 
vention, and in a departure from the prior art, succeed- 
ing unique identifiers provided by a particular userto one 
or more merchants, changes during each of a sequence 
of transactions. As a result, and in accordance with an 
advantage of the invention, knowledge of a number of 
identifiers collected over even a large period of time, will 
not provide any useful information about purchasers 
and their purchases. Whereas the prior art technique of 
each user using the same identifier for multiple transac- 
tions rendered the transactions linkable, the inventive 
technique of using different identifiers for multiple trans- 
actions renders the transactions unlinkable. 
[0008]- In accordance with an embodiment of the in- 
vention, a merchant places the unique identifier re- 
ceived from a user on a package label and provides the 
package to a third party trusted shipper who associates 
the unique identifier with a user and delivers the pack- 
age to the user's address. The shipper, during a previ- 
ous registration process, has already associated multi- 
ple unique identifiers with the particular user. The pre- 
association may be accomplished in various ways. In 
one embodiment, the shipper generates multiple unique 
identifiers and provides these identifiers to the user. 
Both the user and the shipper store these identifiers in 
a computer memory. Thereafter, during an online trans- 
action, the user provides one of the identifiers to the 
merchant. When the shipper receives a package having 
an identifier on the label, the shipper performs a data- 
base lookup in order to find the received identifier and 
to determine the associated user address. 
[0009] In accordance with another embodiment, the 
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user and shipper may generate identifiers dynamically 
based on known values of parameters which have been 
exchanged between the user and the shipper. In accord- 
ance with a particular embodiment, these parameters 
are a unique key assigned to each user, along with a 
counter which is incremented by a known increment al- 
gorithm during successive online transactions. Since 
the counter changes after each transaction, the identi- 
fiers received by merchants in connection with succes- 
sive transactions are different and non-linkable by the 
merchants. In another particular embodiment, the pa- 
rameters are a unique key along with a random number 
generated by the user, 

[0010] Due to possible counter synchronization er- 
rors, which will be described in further detail below, the 
shipper may store multiple records, containing a se- 
quence of unique identifiers, for each user. This allows 
for the technique to operate correctly even in the pres- 
ence of a certain level of synchronization error. In ac- 
cordance with yet another technique, even if the syn- 
chronization error is beyond the certain level, associa- 
tion of an identifier with the appropriate user may still be 
accomplished through the use of extrapolation tech- 
niques. New unique identifiers may be extrapolated us- 
ing shipper database information alone, or in conjunc- 
tion with additional information provided to the shipper. 
[0011] In accordance with another embodiment of the 
invention, an anonymous payment technique is coupled 
with the above described anonymous delivery tech- 
nique. In accordance with this embodiment, the shipper 
pays the merchant for the goods, and the user pays the 
shipper the amount paid for the goods, the shipping 
charge, and an optional transaction processing fee. The 
shipper authenticates the user's agreement to pay for 
the goods using messages and encrypted messages 
sent from the user to the merchant and forwarded from 
the merchant to the shipper. Upon authentication of the 
purchase price, the shipper can be assured that the user 
agreed to pay a specific price for the goods being deliv- 
ered. As such, the shipper can pay the merchant an au- 
thenticated amount for the goods and the shipper can 
be assured that the user agreed to pay the authenticated 
amount for the goods. 

[0012] These and other advantages of the invention 
will be apparent to those of ordinary skill in the art by 
reference to the following detailed description and the 
accompanying drawings. 

Brief Description of the Drawings 

[0013] 

Fig. 1 shows an arrangement of elements and is 
used to describe an embodiment of the invention; 
Fig. 2 shows an arrangement of elements and is 
used to describe another embodiment of the inven- 
tion; 

Fig. 3 illustrates the contents of database records 



and the extrapolation of database information in ac- 
cordance with an embodiment of the invention; 
Fig. 4 shows an arrangement of elements and is 
used to describe another embodiment of the inven- 
s tion; and 

Fig. 5 shows an arrangement of elements and is 
used to describe an embodiment of the invention in 
which a payment technique is coupled to the deliv- 
ery technique. 

10 

Detailed Description 

[0014] One embodiment of the invention will be de- 
scribed in conjunction with Fig. 1 , which represents a 

*s user U 102, a merchant M 104, and a shipper S 106. 
Initially, the user 1 02 and merchant 1 04 are in commu- 
nication and agree that the user 102 will purchase a 
product from merchant 104. This communication is typ- 
ically via a user computer and a merchant computer 

20 communicating via a data network (e.g. the Internet). At 
this point, we will ignore the issue of payment for the 
product. Techniques for adding anonymous payment 
will be described below. Once the terms of the sale have 
been agreed upon, the user 102 sends an identifier, t ft 

25 to the merchant 1 04. In accordance with an aspect of 
the invention, and in a departure from the prior art, the 
identifier sent from a user to a merchant changes with 
each transaction. As such, the notation ll refers to the j 
th identifier ofthe/th user. Thus, for each of a sequence 

30 of transactions, an ith user will send one of a sequence 
of identifiers /], l 2 r l 3 jt I n r Thus, for the first trans- 
action with a merchant, the / th user will send identifier 
/) to the merchant. Thereafter, for the next transaction 
between that same user and the same or different mer- 

35 chant, the user will send the identifier f 2 f . Since the iden- 
tifier changes with each transaction, it is impossible for 
merchants to discover any information about purchas- 
ers, even if in possession of information relating to a 
large number of transactions over a large time period. 

40 As such, the invention substantially reduces the linka- 
bility problem described above. 
[0015] Returning now to Fig. 1, upon receipt of the 
identifier /j, the merchant 104 places the identifier on a 
label 1 08 of the package 1 1 0 containing the product or- 

45 dered by the user 102 during the transaction. At this 
point, the merchant 1 04 does not know the identity of 
the user 1 02 nor the address of the user 1 02. The mer- 
chant 104 does know that the user's identifier for this 
transaction is /(, and that the user 102 has a relationship 

so with shipper 1 06 such that the shipper 1 06 can properly 
deliver the package 110 to the user 102. As such, the 
merchant 104 provides the package 110 to the shipper 
106. 

[0016] Upon receipt of the package 110, the shipper 
55 106 reads the label 108 to determine the identifier t r It 
is noted that the label 108 is advantageously in a ma- 
chine readable format such that the shipper may auto- 
mate the reading of labels. Of course, the particular ma- 
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chine readable format of the label will dictate both the 
technique used by the merchant 1 04 in placing the iden- 
tifier on the label 108 and the technique used by the 
shipper 106 in reading the identifier from the label. As 
one example, the merchant may print a bar code label 
which is readable by the shipper using a bar code scan- 
ner. Once the shipper 1 06 reads the identifier P v the ship- 
per 106 access a database 112 which contains a data- 
base table 1 1 4 which stores associations between iden- 
tifiers and user names and addresses. As shown in Fig. 
1 , the table stores multiple identifiers for each user. For 
example, for user 1, the table 114 is shown storing n 
identifiers. The shipper 1 06 performs a database lookup 
to determine the name and address associated with the 
identifier read from the label 108 for the package 110 
received from the merchant 1 04. The identifiers are de- 
signed such that they are large enough to ensure that 
each identifier uniquely identifies one database record 
and the possibility of duplicates is extremely small and 
assumed not to exist. The generation of the identifiers 
will be described in further detail below. 
[0017] Upon the shipper 106 finding the appropriate 
database record matching the received identifier, the 
shipper 1 06 will place a name and address label 1 1 6 on 
the package 110 and ship the package 110 to the user 
102. Thus, in this way, the user 102 anonymously re- 
ceives a product from the merchant 104. Only the ship- 
per 1 06, who is a trusted third party, can correlate iden- 
tifiers with user names and addresses. As described 
above, a benefit of this technique over the prior art anon- 
ymous delivery methods is that, since a user uses a dif- 
ferent unique identifier for each successive online trans- 
action, the technique of the present invention is not link- 
able. That is, even though merchants may collect trans- 
action information, such information is difficult to link to 
any one particular user. 

[0018] It is noted that the steps described herein as 
being performed by the shipper may be advantageously 
performed using a programmable computer. Such a 
computer comprises a processor for executing compu- 
ter program code stored in a memory which is accessi- 
ble by the processor. As used herein, the term memory 
is used to refer to any computer readable medium, in- 
cluding without limitation, random access memory 
(RAM), read only memory (ROM), magnetic disk, optical 
disk, and holographic memory. In an advantageous em- 
bodiment, the computer program code is stored in a high 
speed memory, such as a RAM, which is connected to 
the computer processor. The computer program code 
required to implement the invention may be written in 
any well known computer language. Given the present 
description of the invention, one of ordinary skill in the 
art to which the invention pertains could readily write the 
program code necessary to implement the invention. 
Further, the computer would communicate with data- 
base 112 in a well known manner. A user interacts with 
the computer using well known input/output devices and 
techniques (e.g. display screen, keyboard, mouse). Pro- 



grammable computers of the type described herein are 
well known in the art and as such, further details are not 
required here. 

[0019] In order for the above described scheme to 

s work correctly, a particular identifier ^ being used by a 
user 1 02 must be p re-associated with that user's name 
and address in the database table 114. There are vari- 
ous techniques for carrying out this pre-association. 
[0020] In a first embodiment, the identifiers to be used 

10 by a particular user are generated in advance by the 
shipper and provided to the user for storage in the user's 
computer. For example, when the user 1 02 desires to 
subscribe for anonymous delivery services as described 
herein, the user registers with the shipper 106 and re- 
's quests a sequence of identifiers. The shipper 1 06 gen- 
erates a number n of such identifiers and provides these 
n identifiers to the user. The shipper stores these n iden- 
tifiers in its database table 114, Thus, the n identifiers 
generated for the ith userwould be /j,/^,/^,..,,/^ These 

20 same n identifiers / J,/*.'^ ,...,/, would also be stored 
in the computer of user A In accordance with this em- 
bodiment, when the shipper receives an identifier t { from 
a merchant, the shipper looks for the unique record that 
contains that identifier to determine the name and ad- 

25 dress for shipping. After an identifier is used, it may be ^ 
deleted from the storage of both the user's computer 
and the shipper's database 112, because, as described 
above, each unique identifier is only used once. It would 
be recognized that this embodiment requires a great 

30 deal of storage, at both the user's computer and at the 
shipper's database. This is so especially in view of the 
fact that the unique identifiers /} must be fairly large to 
ensure that there is no duplication. 
[0021 ] In accordance with another embodiment of the 

35 invention, the user and shipper generate the identifiers 
dynamically, on an as needed basis. In this embodi- 
ment, when a user registers with the shipper as a sub- 
scriber to the service, the shipper provides a unique key 
for the user. For the ith user, we will call this key K f . The 

40 shipper also provides the user with an initial value for a 
counter. For the /th user, we will call this counter C,-. The 
counter will change incrementally, according to some 
known increment algorithm which is known to both the 
user and the shipper. For example, the algorithm may 

4 5 be a simple change in value from C/to C f + s, where s 
is a positive or negative integer. Of course, the incre- 
ment algorithm may be any algorithm known to both the 
shipper and the user. As a simple notation, we will use 
the notation Cy+1 to refer to the counter C f which has 

so been incremented one time in accordance with its incre- 
ment algorithm. In accordance with this embodiment, 
the identifier i. is computed as a one-way function of K) 
and C, such that the user and shipper can dynamically 
generate ^ using knowledge of K,and C h The function 

55 is one-way in that K, and C f cannot be determined from 
a knowledge of /(. 

[0022] This embodiment is illustrated in conjunction 
with Fig. 2. In this embodiment, when the user 202 en- 
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gages in a transaction with the merchant 204, the user 
202 dynamically generates ^ based on values of K/and 
C/Stored in the user's computer and sends the identifier 
/{ to the merchant 204 . The user increments the value 
of Cfto C/+1 based on the increment algorithm so that 
during the next transaction, the user will generate a dif- 
ferent /}. On the shipper side, when the shipper 206 re- 
ceives the package 21 0 from the merchant 204 contain- 
ing the identifier t f on the label 208, the shipper 206 
searches its database 212 for a record containing a 
matching identifier as described above. 
[0023] In accordance with this embodiment, the ship- 
per database 212 stores a database table 21 4 as shown 
in Fig. 2. For each user /, the database table 214 con- 
tains a record storing the unique identifier /{ generated 
using the current value of the counter C h the name and 
address of the user, the current value of the counter C h 
the increment algorithm, and the user's key Kj. 
[0024] When the shipper 206 finds the identifier /{ re- 
ceived on the label 208 in the database table 214, the 
shipper prints a label 21 6 with the name and address 
associated with the identifier and ships the package 21 0 
to the user. In this embodiment, the shipper also updates 
the database record for the user as follows. The shipper 
increments the value of Cj in accordance with the incre- 
ment algorithm in the record. The shipper then com- 
putes a new identifier /j based on K- t and the updated 
value of C t Thus, in this embodiment, the storage con- 
cerns of the above described embodiment are solved 
because the user and shipper store the information re- 
quired to dynamically generate the unique identifiers 
rather than storing a large number of pre-computed 
identifiers. 

[0025] One possible problem with the above de- 
scribed embodiment in which the identifiers are dynam- 
ically generated is that the user and the shipper must 
remain in proper synchronization. That is, the counter 
Cj values maintained by the user and the shipper must 
be the same, or the dynamically generated identifiers 
will not match. There are several ways to encounter syn- 
chronization problems. First, consider the situation in 
which the user sends an identifier f f to a merchant. The 
user then increments its counter C, in accordance with 
the above described technique. However, prior to the 
merchant sending the package having the identifier /[ 
on its label, the merchant computer crashes and the 
merchant looses the information pertaining to the trans- 
action, and so the shipper never receives the identifier 
/{ from the merchant. As such, the shipper never incre- 
ments the counter ^associated with this particular user, 
and thus the user counter Cj and the associated shipper 
counter C, are out of synchronization. During the next 
transaction of this user, the user will generate the next 
identifier based on the incremented counter (i.e., a 
counter value of C,+1)but upon receipt of that identifier, 
the shipper will not be able to find it in its database be- 
cause the record for that user contains an identifier that 
was generated using a non-incremented counter value 



of q. 

[0026] Another way for the user and the shipper to get 
out of synchronization is as follows. Consider a user 
which enters into a transaction with a first merchant and 

5 sends an identifier ^ to the merchant. The user then in- 
crements its counter C } in accordance with the above 
described technique. The user then enters into another 
transaction with a second merchant and sends the next 
identifier /f +1 , based on the incremented counter value 

10 c f +1 to the second merchant. However, the second 
merchant's package reaches the shipper first, so that 
the shipper receives the identifier before receiving 
identifier f.. At this point, the shipper's database record 
for this user still contains the identifier /{. Thus, the sys- 

'5 tern is out of synchronization and will not operate prop- 
erly. 

[0027] One solution to the synchronization problem is 
to configure and maintain a database table 302 as 
shown in Fig. 3. In this embodiment, a sequence of iden- 

20 tif iers is stored for each user. Table 302 shows the stored 
records for the ith user. The table 302 stores n records 
containing the identifiers /j,^,/),...^. These identifiers 
are generated using the ith user's key K t and the incre- 
mental values of the ith user's counter C,to C,+ (n-1), 

25 Thus, even if the shipper receives identifiers which are 
not in the specific order expected (based on the counter 
values), the shipper will still likely have a matching 
record in table 302 to match the received identifier. The 
value of n may be chosen as a balance of storage ca- 

30 pacity of the shipper's database and the extent of non- 
synchronization that the shipper wants to be able to han- 
dle. 

[0028] In accordance with another technique, even if 
the user and shipper become out of synchronization by 

35 an amount greater than the value n, the shipper may 
nonetheless be able to handle the identifier as follows. 
Suppose, in connection with the embodiment shown in 
Fig. 3, that the shipper receives a package containing 
an identifier which does not exist in database table 302. 

40 The shipper may at that time assume that the identifier 
is invalid and terminate processing of the package. 
However, theshippermay attempt to extrapolate the ex- 
isting data in the database table 302 in order to attempt 
to determine the user associated with the package as 

45 follows. The shipper will attempt to calculate the suc- 
ceeding x identifiers for each of the users in the data- 
base table 302. For example, if x=3, then with respect 
to the ith user shown in Fig. 3, the shipper will calculate 
the 3 identifiers in the sequence immediately following 

50 the last identifier stored for that user. Thus, in the em- 
bodiment shown in Fig. 3 in which the shipper stores n 
records for each user, and where the last record for the 
ith user is F r then the shipper will dynamically calculate 
7 +1 ■ I™ 2 , /f +3 using incremental counter values of C^n, 

55 C^-n+1 , Cpn+2 respectively. This extrapolation can be 
thought of as the sh ipper generating another x database 
table records, as illustrated in Fig. 3 as 306. The shipper 
will perform this extrapolation of x records for each of 
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the users until one of the newly generated identifiers 
matches the received identifier, or until the shipper 
makes a determination that the received identifier can- 
not be matched to a user. 

[0029] In the above embodiments in which multiple 
records are stored for each user, some type of table 
maintenance must be performed in order to maintain the 
database table within a reasonable size. For example, 
suppose the shipper stores 10 records for each user, 
and thus for the ith user the database table has records 
containing the following identifiers, f},/^,.../ 10 , Now, 
suppose the shipper receives the identifier /® on a pack- 
age label from a merchant. The shipper matches the 
identifier to the ith user and ships the package to that 
user as described above. The shipper may now make 
the assumption that some synchronization error has re- 
sulted, and that it is now unlikely that the shipper will 
receive some of the earlier sequence identifiers in con- 
nection with that user. As such, and in accordance with 
a table maintenance operation, the shipper may delete 
the records containing the identifiers /*,.../>, since 
these identifiers are unlikely to be received in connec- 
tion with this user. Note that the record containing the 
identifier l 7 f has been left in the database, in case, due 
to further synchronization problems, the user may still 
use that identifier. 

[0030] In yet another embodiment the user may sup- 
ply the merchant with both an identifier ^ and the counter 
Cj which was used to generate the identifier. This em- 
bodiment allow the shipper to more easily extrapolate a 
new identifier as follows. Assume that the shipper has 
1 0 records stored for this particular user and containing 
the following identifiers, /j,/^,/*,.../™. Now assume that 
the user and the shipper are out of synchronization, 
such that the user transmits the identifier to the mer- 
chant. In addition, in accordance with this embodiment, 
the user also transmits to the merchant C,+13, which is 
the counter value used to compute the identifier t] A (re- 
call, with reference to Fig. 3, that the identifier l n f is gen- 
erated using the counter value C,+(n-1 )) . The merchant, 
in turn, places on the package a label containing f] 4 and 
C/+13. Upon receipt of this package, the shipper per- 
forms a database lookup but does not find the identifier 
I}*. In accordance with the above described extrapola- 
tion techniques, the shipper could attempt to generate 
new identifiers for each of the users. However, if, as de- 
scribed above, the number of extrapolations x=3, then 
for this user the shipper will dynamically generate (J* , 
/? 2 ,/, 13 , and the received identifier, /J 4 , will not be 
matched and the package will be undeliverable. How- 
ever, in accordance with this embodiment, when the 
shipper performs an initial database lookup but does not 
find the identifier /J 4 , the shipper will refer to the counter 
value on the label, which is C,+1 3 in this case. The ship- 
per will then attempt to generate an identifier for each 
of the users in the system using the users' keys along 
with the received counter value C/+13. Thus, the ship- 
per only needs to extrapolate once per user, with an im- 



proved chance of generating the appropriate identifier 
and thus resulting in a database match. 
[0031 ] In yet further improvements on this technique, 
the shipper may extrapolate and generate identifiers for 

5 users in a particular order to improve the possibility of 
an eariy database match. For example, since the ship- 
per knows the highest counter value currently stored for 
a particular user, the shipper may determine that if the 
range of counter values stored in the database for a par- 

10 ticularuseris already beyond the counter value received 
from the merchant, then it is unlikely that this particular 
user generated the identifier in question, and the shipper 
may skip this user and not dynamically generate an 
identifier. In accordance with yet another performance 

15 improvement, the shipper may attempt to order the ex- 
trapolations so that an identifier for the most likely user 
is attempted first. For example, if a particular user has 
stored records containing counter values in the range 
C/to C/+10, and the shipper received the counter C f +11 

20 on the label, the shipper may make a judgment that 
since the counter is only out of synchronization by one 
. increment, that this user is a likely candidate for extrap- 
olation. 

[0032] It is noted that the above described technique 
25 of the user sending the counter C, along with the iden- 
tifier may, in a limited number of cases, allow the mer- 
chant to associate certain purchases with a particular 
user. For example, since the merchant receives the 
counters, the merchant may collect these counters and 
30 attempt to make some determination of the increment 
algorithms and thus make some correlation between 
transactions. For example, assume over time a mer- 
chant receives the following combinations of identifiers 
and counters. 

35 



40 



45 



TX ID 


IDENTIFIER 


COUNTER 


1 


123324384895 


1 


2 


139483948395 


129 


3 


957395739584 


2 


4 


494958928923 


55 


5 


957802852949 


131 


6 


958395038503 


88 


7 


472395023782 


133 


8 


594848582385 


3 



so [0033] Upon analysis of the counters, a merchant 
could very well make the assumption that the same user 
is associated with transaction identifiers (TX ID) 1, 3, 
and 8 because the counters for the transactions are 1 , 
2, and 3 respectively, which would be associated with 

55 an increment algorithm of C f =Cj +1 . Similarly, a mer- 
chant could also make the assumption that the same 
user is associated with TX IDs 2, 5, and 7 because the 
counters for the transactions are 1 29, 1 31 , and 1 33 re- 
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spectively, which would be associated with an increment 
algorithm of C f =C,+2. Of course, these examples are 
simple examples of the analysis which may be done by 
a merchant, but they illustrate the possible danger of 
providing a merchant with counter values. 
[0034] I n order to prevent the above described corre- 
lation, in accordance with another embodiment of the 
invention, the user supplies the merchant with both an 
identifier /{, and an encryption of the counter C, which 
was used to generate that identifier. Advantageously, 
the shipper provides users with the public key portion of 
a public key / private key pair in accordance with well 
known public key/ private key encryption schemes. The 
user encrypts the counter C f using the public key. The 
public key of the shipper is denoted as PK S and the en- 
cryption of the counter C } using the public key PK S is 
denoted as E PKs (Cj). Thus, the user sends to the mer- 
chant ^ and E PKs (C,). The merchant in turn sends these 
parameters to the shipper. In a manner similar to that 
described above, if the shipper cannot find a record with 
a matching identifier /[ in its database, it can decrypt the 
counter and use it to extrapolate a new identifier as de- 
scribed above. In this case, however, the counters re- 
ceived by the merchant are encrypted, and therefore the 
merchant cannot discover any useful information from 
the counters. It is noted that Ep Ks (Cj) may be fairly large, 
and as such, it may be difficult for the merchant to en- 
code the encrypted counter on a standard shipping la- 
bel. As such, in a variation of this embodiment, the mer- 
chant may only place the identifier /J on the shipping la- 
bel. If the shipper cannot find a record with a matching 
identifier in its database, only then does the shipper re- 
quest the associated E PKs (Cj) from the merchant. The 
merchant may send another label containing ^ and E PKs 
(Q, or E PKs {Cjj may be transmitted electronically from 
the merchant to the shipper. 

[0035] We now describe another embodiment of the 
invention in which the user and shipper generate iden- 
tifiers dynamically, on an as needed basis, but without 
the use of a counter. In a manner similar to that de- 
scribed above in conjunction with Fig. 2, when an ith us- 
er registers with the shipper as a subscriber to the serv- 
ice, the shipper provides the user with a unique key K h 
which is known to both the user and the shipper. The 
identifier f. in this embodiment is computed as a one- 
way function of K^and a random number R which is gen- 
erated by the user for each transaction. 
[0036] This embodiment is illustrated in conjunction 
with Fig. 4. When the user 402 engages in a transaction 
with the merchant 404, the user 402 dynamically gen- 
erates $1 based on the values of K h and a random 
number R which is generated by the user 402. The user 
402 sends the identifier ^ and the random number A? to 
the merchant 404. The merchant 404 places the identi- 
fier ^ and random number R on label 408 of package 
41 0 and provides the package to the shipper 406. 
[0037] In accordance with this embodiment, the ship- 
per database 41 2 stores a database table 41 4 as shown 



in Fig. 4. For each user /, the database table 414 con- 
tains a record storing the name and address of the user 
and the user's key K { . When the shipper 406 receives 
the package 410, it reads the identifier and random 
5 number R on label 408. The shipper then uses the re- 
ceived random number R, along with the same one-way 
function the user 402 used to generate the received 
identifier, to generate new identifiers using each of the 
keys K/inthedatabasetable414. The shipper continues 
10 generating identifiers until one of the generated identi- 
fiers matches the received identifier. When a matching 
identifier is generated, the shipper knows that the key 
Kj which was used to generate the matching identifier 
belongs to the i'th user associated with the package, and 
*s the shipper can read the associated name and address 
of the /th user from the table 414. The shipper then 
prints a label with the name and address of the user and 
ships the package to the user. 
[0038] It is noted that although this embodiment, in 
some cases, is more computationally intensive that the 
above described embodiments which use counters, this 
embodiment solves the synchronization problem of the 
counter embodiments because there is no requirement 
for the shipper or user to save any state information (e. 
g. counter values). In addition, this embodiment does 
not allow the shipper to determine any information about 
the user using the received random number. 
[0039] Another embodiment in which a random 
number is used in the dynamic generation of an identifier 
is as follows. In this embodiment, a user generates an 
identifier by encrypting his/her address appended with 
a random number R, and transmits the encrypted text 
to the merchant. The merchant places the encrypted 
text on the label and provides the package to the ship- 
per. Upon receipt of the package, the shipper reads the 
encrypted text, decrypts the encrypted text, and extracts 
the user's name and address. Note that in this embod- 
iment, the shipper only needs to store a key which can 
be used to decrypt the encrypted text. Various well 
known encryption techniques, including public key/ pri- 
vate key encryption schemes, may be used in conjunc- 
tion with this embodiment. 

[0040] We will now address authentication of a mon- 
etary payment to the merchant in conjunction with Fig. 
5. As described above, one of the problems with anon- 
ymous electronic commerce is that payment must be 
made from the user to the merchant. Since such pay- 
ment is generally made by credit card, the merchant 
must know the user's name in order to process the pay- 
ment. This severely limits the possibility of anonymous 
electronic commerce. Although payment may be ar- 
ranged through another trusted third party, it would be 
logistically difficult to coordinate such a combination of 
trusted third party payee, trusted third party shipper, pur- 
chaser, and merchant. As such, in another embodiment 
of the invention described below, we provide an im- 
proved payment technique which may be used in con- 
junction with the above described anonymous delivery 
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techniques. In accordance with this embodiment, the 
merchant receives payment from the shipper, and the 
shipper may then recover the amount of the payment 
(plus an optional transaction processing fee) from the 
user. In this embodiment, identifiers t. are dynamically 
generated by the users as described above, but the 
identifiers are broken into two parts, part\(fy and parti 
(/(). For example, if f f is 32 bits, then the first 16 bits 
would be parti (/{) and the second 1 6 bits would be part2 
(/{). As shown in Fig. 5, the shipper database table 514 
stores these two. parts of the identifier. The user 502, 
generates a message which is used for payment author- 
ization associated with an electronic transaction. For ex- 
ample, a typical message may be "pay $1 00". The user 
502 then generates a secret S, by encrypting the mes- 
sage in accordance with a well known message authen- 
tication code (MAC) technique while using the second 
part of an identifier as the MAC key as follows: S, = 
MAC part2(/)( messa Q e )- u P on completion of a transac- 
tion with ttfe merchant 504, the user 502 transmits the 
following parameters to the merchant 504: partt{(t f ),S h 
message, E PK} (C,). Upon receipt of these parameters, 
the merchant 504 prepares a label 508 for the package 
510 containing the item ordered by the user 502 and 
sends the package 51 0 to the shipper 506. As described 
above, the parameters sent to the merchant 504 by the 
user 502 may be too lengthy to conveniently be encoded 
on the package label 508, and as such, some of the pa- 
rameters may be transmitted to the shipper 506 by the 
merchant 504 in another manner (e.g. electronically) as 
illustrated in Fig. 5 by the broken line 530. Advanta- 
geously, the label 508 contains the identifier parfl^) 
and the other parameters associated with that identifier, 
namely Sf, message, E PKj (C,) are transmitted to the 
shipper electronically. 

[0041] Upon receipt of the package 51 0, the shipper 
506 performs a database search for the parti (/() which 
was on the label 508. If found, the shipper 506 takes the 
associated part2(^) from the database record, and the 
message received electronically from the merchant 504, 
and computes the secret S f = MAC^i/ ^message). If 
the computed secret S f matches the secfet S, received 
electronically from the merchant 504, then the shipper 
506 determines that user 502 must have agreed to pay 
the price specified in the message, because otherwise 
the merchant 504 could not have computed a secret S,- 
which matches the secret S, computed by the shipper 
506. In this case, the shipper 506 can pay the merchant 
504 the amount specified in the message, deliver the 
package 510 to the user 502, and charge the user 502 
the shipping charge, the amount the shipper paid to the 
merchant, plus an appropriate transaction fee for han- 
dling the payment. It is also noted that if the computed 
secret S f matches the secret Sf received from the mer- 
chant 504, then the user 502 cannot deny having agreed 
to make the payment. 

[0042] If the computed secret S, does not match the 
secret S, received from the merchant 504, then there, is 



a problem and appropriate exception handling would 
take place. It is further noted that if, upon receipt of the 
package 510, the shipper 506 cannot find partify in its 
database 512, then the extrapolation techniques de- 
5 scribed above may be used. . 

[0043] The foregoing Detailed Description is to be un- 
derstood as being in every respect illustrative and ex- 
emplary, but not restrictive, and the scope of the inven- 
tion disclosed herein is not to be determined from the 
10 Detailed Description, but rather from the claims 

[0044] It is to be understood that the embodiments 
shown and described herein are only illustrative of the 
principles of the present invention and that various mod- 
ifications may be implemented by those skilled in the art 
*5 without departing from the scope . of the invention. For 
example, various modifications and variations to the pa- 
rameters passed, and the encryption of such parame- 
ters would be readily apparent to one skilled in the art. 
For example, the user may pass to the merchant an en- 
crypted value of / representing the user's identification 
and/or other encrypted parameters, which if passed to 
the shipper, could improve the performance of the da- 
tabase lookup. 



1 . A method comprising the steps of: 

30 receiving an identifier from a merchant; 

identifying one of a plurality of users based on 
said received identifier, wherein each of said 
plurality of users may be identified based on at 
least two different received identifiers; and 
35 determining an address of said one user. 

2. The method of claim 1 further comprising the step 
of: 

shipping a package to said one user at said 
40 determined address. 

3. The method of claim 1 wherein said step of identi- 
fying comprises the step of: 

performing a database lookup using said re- 
4 $ ceived identifier. 

4. The method of claim 3 further comprising the step 
of: 

if said database lookup fails to identify said 
so one user, then: 



generating at least one identifier; and 
comparing said generated identifier with said 
received identifier. 

55 

5. The method of claim 4 wherein said step of gener- 
ating at least one identifier comprises.the step of: 
generating said at least one identifier using in- 
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• formation stored in said database. 

6. The method of claim 5 wherein said step of gener- 
ating at least one identifier comprises the step of: 

generating said at least one identifier using 
additional information received from said merchant. 

7. The method of claim 6 wherein said additional in- 
formation received from said merchant includes a 
counter. 

8. The method of claim 7 wherein said counter is en- 
crypted. 

9. The method of claim 1 wherein said identifier is re- 
ceived from said merchant on a package label. 

10. The method of claim 1 wherein said received iden- 
tifier is a first portion of a stored value, said method 
further comprising the steps of: 

receiving a message and a first encrypted mes- 
sage from said merchant; 
retrieving a second portion of said stored value; 
encrypting said received message using said 
second portion of said value to generate a sec- 
ond encrypted message; and 
determining whether said first encrypted mes- 
sage matches said second encrypted mes- 
sage. 

1 1 . The method of claim 1 0 further comprising the step 
of: 

validating said received message if said first 
encrypted message matches said second encrypt- 
ed message. 

12. The method of claim 11 wherein said message in- 
dicates a monetary amount. 

13. The method of claim 1 wherein said step of identi- 
fying comprises the step of: 

generating at least one identifier using infor- 
mation stored in said database. 

,14. The method of claim 13 wherein said step of gen- 
erating at least one identifier comprises the step of: 
generating said at least one identifier using 
additional information received from said merchant. 

15. The method of claim 14 wherein said additional in- 
formation received from said merchant includes a 
counter. 

16. The method of claim 14 wherein said additional in- 
formation received from said merchant includes a 
random number. 



17. A system comprising: 

means for reading an identifier received from a 
merchant; 

5 means for identifying one of a plurality of users 

based on said received identifier, wherein each 
of said plurality of users may be identified 
based on at least two different received identi- 
fiers; and 

10 means for determining an address of said one 

user. 

18. The system of claim 1 7 where said means for read- 
ing an identifier comprises: 

'5 a bar code scanner. 

19. The system of claim 17 wherein said means for 
identifying comprises: 

means for performing a database lookup us- 
20 ing said received identifier. 

20. The system of claim 19 further comprising, for use 
when said database lookup fails: 

25 means for generating at least one identifier; 

and 

means for comparing said generated identifier 
with said received identifier. 

30 21 . The system of claim 20 wherein said means for gen- 
erating at least one identifier comprises: 

means for generating said at least one iden- 
tifier using information stored in said database. 

35 22: The system of claim 21 wherein said means for gen- 
erating at least one identifier further comprises: 

means for generating said at least one iden- 
tifier using additional information received from said 
merchant. 

40 

23. The system of claim 22 wherein said additional in- 
formation received from said merchant includes a 
counter. 

45 24. The system of claim 23 wherein said counter is en- 
crypted. 

25. The system of claim 1 7 wherein said identifier is re- 
ceived from said merchant on a package label. 

50 

26. The system of claim 1 7 wherein said received iden- 
tifier is a first portion of a stored value, said system 
further comprising: 

5 5 means for receiving a message and a first en- 

crypted message from said merchant; 
means for retrieving a second portion of said 
stored value; 
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means for encrypting said received message 
using said second portion of said value to gen- 
erate a second encrypted message; and 
means for determining whether said first en- 
crypted message matches said second en- 
crypted message. 

27. The system of claim 26 further comprising: 

means for validating said received message 
if said first encrypted message matches said sec- 
ond encrypted message. 

28. The system of claim 27 wherein said message in- 
dicates a monetary amount. 

29. The system of claim 17 wherein said means for 
identifying comprises: 

means for generating at least one identifier 
using information stored in said database. 

30. The system of claim 29 wherein said means for gen- 
erating at least one identifier comprises: 

means for generating said at least one iden- 
tifier using additional information received from said 
merchant. 

31. The system of claim 30 wherein said additional in- 
formation received from said merchant includes a 
counter. 

32. The system of claim 30 wherein said additional in- 
formation received from said merchant includes a 
random number 
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received identifier with an address, said database 
comprising a plurality of records with each record 
comprising a plurality of fields for storing data, each 
of said records storing at least: 

a unique identifier; 
a counter; 
a key; and 
an address; 

said database characterized In that: 

said unique identifier is a function of said 
counter and said key. 

37. The database of claim 36 wherein a particular ad- 
dress occurs in only one database record. 

38. The database of claim 37 wherein when a received 
identifier matches a stored unique identifier in one 
of said database records; 

said counter is said one database record is in- 
cremented; and 

said unique identifier in said one database 
record is updated. 

39. The database of claim 36 wherein a particular ad- 
dress occurs in at least two database records. 

40. The database of claim 36 wherein said identifier 
comprises a first part and a second part. 



33. A database for use by a shipper for associating a 
received identifier with an address, said database 
comprising a plurality of records with each record 
comprising a plurality of fields for storing data, each 
of said records storing at least: 

a unique identifier; and 
an address; 

said database characterized in that: 

at least two records contain different 
unique identifiers and the same address. 



35 



40 



45 



34. The database of claim 33 wherein each of said 
records further stores at least: 



a counter; and so 
a key; 

wherein said unique identifier is a function of 
said counter and said key. 

35. The database of claim 33 wherein said unique iden- 55 
tifier comprises a first part and a second part. 

36: A database for use by a shipper for associating a 
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